normalizedTupleType does the opposite of what we want. We need to convert TupleN to *: equivalent. I found this function in TypeUtils.scala that does exactly this:

Also note that tp.normalized on TupleN returns NoType.

Using this function, the code is cleaner and more readable:

def apply(n: Int, tp: Type): Int =
  tp match {
    case tp: AppliedType if defn.isTupleNType(tp) =>
      foldOver(n + 1, tp.toNestedPairs)
    // From here the following code is the same as the original
    case tp: AppliedType =>
      val tpNorm = tp.tryNormalize
      if tpNorm.exists then apply(n, tpNorm)
      else foldOver(n + 1, tp)
    ...

We need to convert TupleN to *: equivalent.

Why not do the opposite? TupleN needs less object allocations.

Also note that tp.normalized on TupleN returns NoType.

Maybe the following would work?

  tp match {
    case tp: AppliedType =>
      val tpNorm = tp.tryNormalize
      if tpNorm.exists then apply(n, tpNorm.normalizedTupleType)
      else foldOver(n + 1, tp.normalizedTupleType)

The above has the advantage that it always normalizes the type, even when it's a tuple.

The motivation of this issue is that the concatenation type of two tuples is made by a Match Type. When a TupleN and another tuple were to be concatenated, the result type uses the *: equivalent. The resulting typeSize is larger and created a lot of false positives in the algorithm of PR #24661

Yes, but from my understanding, the requirement is simply that both TupleN and nested *: pairs be normalized to the same representation. Does it matter whether TupleN is normalized to nested pairs, or vice versa? If we normalize to TupleN, then both types in the unit tests would have size 1, wouldn't they?

Well, I guess for your current implementation of match types termination checks, it's better if (1, 2) and (1, 2, 3) have sizes 2 and 3.